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(54) Multipoint control unit coordinator 

(57) A multipoint control unit coordinator (MCUC) 
105. The MCUC 105 tracks all conferences in a tele- 
communications system and determines how they can 
be best configured and modified over time. The MCUC 
1 05 instructs muitipoint control units MCUs 1 04 to break 
down and reconfigure calls, if necessary. A MCUC 105 
according to an embodiment of the invention maintains 
a database of all the MCUs 1 04 in the system, a meas- 
ure of processing coding resources, and a geographical 




location. When two parties seek to add a third in a con- 
ference call, the MCUC 105 determines coding 
resources, geographical locations, and determines the 
most appropriate mixing location based on preferences, 
such as network cost or endpoint coding resources or 
quality. The MCUC 1 05 then instructs the MCUs 1 04 to 
handle the conference accordingly. 



iooa 



a 

LU 



Printed by Xerox (UK) Business Services 
2.16.7 <HRS)/3.6 



EP 1 091 550 A2 



Description 



[0001] The present invention relates to telecommu- 
nications systems and, particularly, to an improved sys- 
tem and method for multimedia conferencing. 
[0002] The ITU-T (International Telecommunica- 
tions Union Telecommunications Sector) Recommen- 
dation H.323 defines a set of protocols for 
communicating using audio, video and data over 
packet-switched networks, such as for communication 
in telephony-over-local area network (ToL) systems. To 
accommodate multipoint conferences (i.e., those involv- 
ing three or more parties), the Recommendation H.323 
defines a multipoint control unit (MCU) to coordinate the 
conferencing. In particular, the MCU is required by the 
Recommendation H.323 to include a multipoint control- 
ler (MC), which handles H.246 signaling. In addition, the 
MCU may include one or more multipoint processors 
(MP), which mix and process the data streams. The 
MPs may also provide conversion, or transcoding, 
between different codecs. 

[0003] In a centralized multipoint conference mode, 
the MCU handles call signaling, mixes audio and video 
streams, performs transcoding, and re-transmits the 
results to all parties to the conference. In a decentral- 
ized multipoint conference mode, the MCU does not 
process the media streams, which are instead handled 
directly between the endpoints. 

[0004] Once a conference call is established, there 
is no way in conventional H.323 systems to change from 
a centralized to decentralized mode, or vice versa, as 
parties are added. Further, there is no way to switch 
from one MCU to another. That is, there is no way to 
change the site of the mixing of the media streams. 
Moreover, there is no way for an administrator to select 
a preference in choosing the site of the mixing of the 
media streams. Thus, as parties are added sequentially 
to a conference, sub-optimal mixing locations may be 
used. 

[0005] This is illustrated by way of example in FIGs. 
1 A and IB. As seen in FIG. 1 A, an endpoint User A calls 
an endpoint User B. The endpoint User A then confer- 
ences in User C. Because the endpoint User A has suf- 
ficient resources, the endpoint User A handles the 
media mixing for the conference (i.e., the decentralized 
model), as represented by paths A-B and A-C. Call sig- 
naling is handled with the MCU, in a known manner. 
[0006] The endpoint User B may then wish to add 
an endpoint User D to the conference. However, if the 
endpoint User B does not have on-board mixing 
resources, a request will be made to the MCU to handle 
the mixing. The result is seen in FIG. IB. The connec- 
tions are now endpoint User A to MCU (A-MCU), end- 
point User A to endpoint User C (A-C), endpoint User B 
to MCU (B-MCU), and endpoint User D to MCU (D- 
MCU). In effect, two conferences are occurring: When 
endpoint User A mixes media streams of MCU and end- 
point User C, the MCU input is actually the result of the 



endpoint User B and endpoint User D media mix. When 
the MCU mixes media streams of endpoints A, B and D, 
the endpoint User A media input to the MCU is already 
the result of the endpoints A and C media mix. 
5 [0007] As more calls are added, additional mixing 
locations may be necessary. If the ToL system spans a 
WAN (wide area network) or uses a gateway to connect 
to another system, long distance charges may be 
incurred as a result of poor mixing choices. 
io [0008] In such situations as well as other situations, 
it can be desirable to select a preference between long 
distance network cost or processor resource use in ToL 
multipoint conferencing. 

[0009] These and other drawbacks in the prior art 
is may be overcome in large part by a telecommunications 
network, device, method and system in accordance with 
embodiments of the invention. 

[0010] The invention is defined in the independent 
claims, to which reference should now be made. Further 
20 advantageous features are detailed in the dependent 
claims. 

[001 1 ] For example, a telecommunications network 
includes a multipoint control unit coordinator (MCUC). 
The MCUC tracks all conferences in the system and 
25 determines how they can be best configured and modi- 
fied over time. The MCUC instructs MCUs to break 
down and reconfigure calls, if necessary. 
[001 2] A MCUC according to an embodiment of the 
invention maintains a database of ail the MCUs in the 
30 system, a measure of processing coding resources, and 
a geographical location. When two parties seek to add 
a third in a conference call, the MCUC determines cod- 
ing resources, geographical locations, and determines 
the most appropriate mixing location based on such 
35 preferences. The MCUC then instructs the MCUs to 
handle the conference accordingly! 
[0013] A better understanding of the invention is 
obtained when the following detailed description of 
embodiments thereof is considered in conjunction with 
40 the following drawings in which: 
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50 



55 



FIG. 1A and FIG. 1B illustrate operation of an MCU 
according to the prior art; 

FIG. 2 illustrates a telecommunications network 
according to an embodiment of the invention; 
FIG. 3 illustrates a multipoint control unit according 
to an embodiment of the invention; 
FIG. 4 is a flowchart illustrating operation of an 
embodiment of the invention; 
FIG. 5 is a flowchart illustrating operation of another 
embodiment of the invention; and 
FIG. 6 is a flowchart illustrating operation of another 
embodiment of the invention. 

[0014] FIGs. 2 - 6 illustrate an improved multipoint 
conferencing system and methods. The present inven- 
tion provides for more optimal selection of media stream 
mixing locations in multipoint conferencing. Optimal 
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selection of media stream mixing locations may be 
based on network cost or on endpoint coding resources. 
Moreover, such optimization may occur as new users 
are added to the multipoint conference. Optimization of 
network cost may be based on minimizing long distance 5 
costs, for example. Optimization of endpoint coding 
resources may be based on, for example, determining 
an MCU with the most available coding resources or 
optimizing quality levels. 

[001 5] Turning now to the drawings, and with partic- w 
ular attention to FIG. 2, a diagram illustrating an exem- 
plary H.323 telecommunications system 90 according 
to an embodiment of the present invention is shown. It is 
noted that, while described specifically in the context of 
voice packets, the present invention encompasses the 15 
use of any multimedia information, such as video, data, 
voice, or any combinations thereof. Moreover, an exem- 
plary generic H.323 system is the Siemens HiNet™ RC 
3000 system, available from Siemens. 
[0016] As shown, the H.323 telecommunications 20 
system 90 includes a pair of telecommunications zones 
or networks 100a, 100b. Each telecommunications 
zone 100a, 100b includes a local area network (LAN) or 
packet network 101a. 101b. Coupled to the LANs 101a, 
101b may be a variety of H.323 terminals 102a, 103a, 25 
102b, 103b, respectively, multipoint control units (MCU) 
104a, 104b according to the present invention, H.323 
gateways 106a, 106b, H.323 gatekeepers 108a, 108b, 
LAN servers 1 12a, 1 12b and a plurality of other devices 
such as personal computers (not shown). The H.323 30 
terminals 102a, 102b, 103a, 103b are in compliance 
with the H.323 Recommendation. Thus, the H.323 ter- 
minals 102a, 102b, 103a, 103b support H.245 control 
signaling for negotiation of media channel usage, Q.931 
(H.225.0) for call signaling and call setup, H.225.0 Reg- 35 
istration, Admission, and Status (RAS), and RTP/RTCP 
for sequencing audio and video packets. The H.323 ter- 
minals 102a, 102b, 103a, 103b may further Implement 
audio and video codecs, T.1 20 data conferencing proto- 
cols and MCU capabilities. Further details concerning <o 
the H.323 Recommendation may be obtained from the 
International Telecommunications Union. 
[0017] The MCUs 104a, 104b include multipoint 
control unit coordinators (MCUC) 105a, 105b according 
to the present invention. As will be described in greater 45 
detail below, the MCUCs 105a, 105b are used to coor- 
dinate multipoint conferencing and relay multipoint con- 
ference requests to MCUs, as appropriate. Moreover, 
while shown in the context of a plurality of zones, a sin- 
gle MCUC may be employed within a single zone. Fur- so 
thermore, while shown associated with an MCU 104, 
the MCUCs 15a. 105b may be a stand-alone unit or 
placed on any network device. Thus, the figure is exem- 
plary only. 

[0018] As shown in FIG. 3, each exemplary MCU ss 
104 includes a Multipoint Processor (MP) 110 and a 
Multipoint Controller (MC) 112, as well as a Multipoint 
Control Unit Coordinator 105. The MP 110 effects the 



actual media signal processing, i.e., switching, and the 
like. The MC 1 12 handles H.245 capability negotiations 
to determine existence of a common codec. As will be 
explained in greater detail below, the MCUC 105 pro- 
vides for more optimal selection of the media stream 
mixing location. Thus, the MCUC 105 includes a stor- 
age unit 290 for storing network information relevant to 
the multipoint conferencing. The storage unit 290 may 
include MCU information 300a (i.e., an identification of 
the MCUs within the system), a coding resources stor- 
age 300b (i.e., an identification of the endpoint termi- 
nals' coding resources), and a geographical identifier 
300c for identifying locations of the MCUs within the 
network. The MCUC 105 is configured to forward MCU . 
call conference commands to the appropriate MCU. 
[0019] When two parties seek to add a third to a 
conference call, the request is provided, for example, by 
a gatekeeper, to the MCUC 1 05. For example, end- 
points User A and User B (102a, 103a) (FIG. 2) may be 
involved in a conference and seek to conference in User 
102b. The gatekeeper (GK1 ) 1 08a provides this request 
to the MCUC 105a. The MCUC 105a checks the geo- 
graphical location of the three parties and the availabil- 
ity of the DSP resources in each, of the three parties if 
they are registered as MCU providers themselves (i.e., 
if they are configured to handle decentralized confer- 
encing). The MCUC 105a then consults the predeter- 
mined preferences of the system which may be, for 
example, either to optimize (that is, minimise) network 
costs or to optimally balance coding resources. 
[0020] If "optimize network cost" is selected, the 
MCUC 105a will select among all of the MCU resources 
to determine which MCU will result in the least number 
of network connections. Wide area network (WAN) con- 
nections are considered first, then local area network 
(LAN) connections. If more than one MCU resource can 
provide the same optimal cost, coding resources may 
be considered. 

[0021] If "optimally balance coding resources" is 
selected, the MCUC 105a will attempt to select the 
MCU with the most free resources that can handle the 
call in question. If more than one MCU has the same 
amount of available coding resources, then geographi- 
cal location may be considered, as described above. In 
either case, the MCUC 1 05a decrements the available 
coding resources in the chosen MCUs entry in the data- 
base, based on the codecs selected for the call. 
[0022] If one of the parties seeks to add an addi- 
tional caller, the MCUC 105a checks the database to 
determine the optimal location for the mixing if the new 
caller is added. If the location stays the same, the 
MCUC 105a instructs the MCU being used to add the 
new caller and its resources are decremented in the 
database. If a new MCU is to be selected, then the orig- 
inal MCU is asked to transfer the calls to the new MCU, 
which accepts them to begin the new conference. The 
database is decremented to reflect new resource 
usage. 
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[0023] If multiple locations are Involved, or when no 
single MCU can be found to handle all the mixing, 
MCUC 105a can optionally Invoke multiple MCUs to 
form the call. For example, invoking the MCU 1 04a and 
the MCU 104b to handle local parties may minimize the 
long distance costs. That is, the only out-of-network 
communications will be between the MCUs 104a, 104b, 
and not directly between parties. 
[0024] Turning now to FIG. 4, a flowchart illustrating 
general operation of the embodiment of the present 
invention of FIG. 2 is shown. In a step 402, the MCUCs 
105a, 105b receive and store preference information. 
Such preference information is provided by a network 
administrator and may include, for example, a network 
cost preference or a coding resources preference. In a 
step 404, the MCUCs 105a, 105b receive and store 
MCU information. As discussed above, this includes 
coding resources related to MCU-capable devices, as 
well as the location of MCUs and MCU-capable devices. 
In a step 406, one of the MCUCs 1 05a, 105b, for exam- 
ple, MCUC 105a, receives conference call setup 
requests, including, for example, identifications of the 
parties involved and their locations. Then, in a step 408, 
that MCUC accesses its database for information con- 
cerning MCUs related to the conferencing parties! For 
example, this may include geographical location infor- 
mation as well as coding resource information. Next, in 
a step 410, the MCUC 105a identifies the optimal MCU 
or MCUs based on the criteria which were loaded in 
step 402. For example, the optimal criteria may be 
based on minimizing network usage costs, or may be 
based on using the most available coding resources of 
the parties and the MCUs to the conference. Next, in a 
step 412, the MCUC 105a directs the appropriate MCU 
or MCUs, for example, the MCU 104a, to take charge of 
the multipoint conference. Thus, the appropriate MCU 
or MCUs handle the multipoint conference signaling 
and/or the media mixing. 

[0025] Turning now to FIG. 5, a flowchart illustrating 
operation of an exemplary embodiment of the invention, 
for example, that of FIG. 2, is shown in greater detail. In 
a step 502, the MCUC 105a receives preference infor- 
mation. As discussed above, such preference informa- 
tion includes, for example, coding resource optimization 
versus network cost optimization preferencing. In a step 
504, the MCUC 1 05a receives the database information 
related to the MCUs that are present in the network sys- 
tem. Next, in a step 506, an endpoint User A attempts a 
call to an endpoint User B, for example by executing an 
ARQ/ACF exchange and sending call setup commands 
to the gatekeeper (GK1) 108a Next, in a step 508, the 
gatekeeper GK1 relays the call setup information to the 
endpoint Client B. The endpoint Client B responds, in a 
step 510, with an ARQ/ACF exchange with the gate- 
keeper. Then, in a step 512, the endpoint User B sends 
an H.245 Alerting and Connect message to the gate- 
keeper GK1. The gatekeeper GK1 then forwards the 
Alerting and Connect message to the endpoint User A, 



in a step 514. A media channel is established between 
the endpoints A and B in a step 516. 
[0026] In a step 51 8, the endpoint User B requests 
to conference in the endpoint User C. In a step 520, the 
s endpoint User B sends the appropriate call setup infor- 
mation to its gatekeeper GK1. which then sends this 
information to the local MCUC 105a. In a step 522, the 
MCUC 105a accesses its database for information 
related to MCUs associated with the existing and 
10 requested parties to the conference. In particular, the 
MCUC 105a determines the optimal mixing location 
based on the stored preferences. In a step 524, the 
MCUC 105a selects an MCU, for example, the MCU 
104a as the optimal mixer. The MCU 104a then per- 
15 forms multipoint conferencing setup with the endpoints 
User A and User B, and then, via the gateways 106a, 
1 06b, with the endpoint User C, in a step 526. Next, in a 
step 528, the MCUC 105a updates its coding resources 
database to account for the MCU I04a*s mixing of the 
20 multipoint conference. 

[0027] In a step 530, the User C seeks to confer- 
ence in the User D and issues the appropriate call setup 
and signaling commands. In a step 532, the call setup 
and signaling commands are received by the MCUC 
25 1 05a. In a step 534, the MCUC 1 05a accesses its data- 
base to determine the optimal mixing location based on 
the stored criteria. 

[0028] In a step 536, the MCUC 105a determines 
whether the current mixing location is optimal or 
30 whether a new site is more optimal. If a new site is more 
optimal, then the MCUC 105a directs, the correspond- 
ing MCU to take over. For example, the MCUC 105a 
may direct the MCU 104b to take over the mixing for the 
conference, in a step 538. In this case, the MCU 104b 
35 may disconnect the parties to the conference and then 
re-establish the conference itself, in a step 540. Alterna- 
tively, if the users are equipped with secondary signal- 
ing and/or media channels, the conference based on 
the new mixing may be established before closing out 
40 the one based on the previous mixer. Back in step 536, 
if the current mixing location is optimal, the new party! 
endpoint User D is added and the coding resources 
database updated accordingly, in a step 542. 
[0029] Turning now. to FIG. 6, a flowchart illustrating 
45 operation of another exemplary embodiment of the 
invention is shown. In particular, in the embodiment 
illustrated, a distributed MCU system is employed by the 
MCUC to achieve the desired optimization levels. Thus, 
for example, MCUs perform mixing for local client termi- 
so nals but jointly handle mixing for inter-network commu- 
nications. With reference to FIG. 2, for example, the 
MCU 104a handles mixing for client terminals User A 
1 02a and User B 1 03a, and the MCU 1 04b handles mix- 
ing for client terminals User C 102b and User D 103b. 
55 Such a preference may be configured as a predeter- 
mined default by a system administrator. 
[0030] In a step 602, the MCUCs 105a, 105b 
receive preference information. As discussed above, 
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such preference information includes, for example, cod- 
ing resource optimization versus network cost optimiza- 
tion preferencing. In a step 604, the MCUCs 105a, 105b 
receive database information related to the MCUs and 
MCU-capable terminals that are present in the network 
system. Next, in a step 606, an endpoint User A 
attempts a call to an endpoint User B, for example by 
executing an ARQ/ACF exchange and sending call 
setup commands to the gatekeeper (GK1) 108a. Next, 
in a step 608, the gatekeeper GK1 relays the call setup 
information to the endpoint User B. The endpoint Client 
B responds, in a step 610, with an ARQ/ACF exchange 
with the gatekeeper GK1. Then, in a step 612, the end- 
point User B sends an H.245 Alerting and Connect 
message to the gatekeeper GK1 . The gatekeeper GK1 
then forwards the Alerting and Connect message to the 
endpoint User A, in a step 614. A media channel is 
established between the endpoints A and B in a step 
616. 

[0031] In a step 61 8, the endpoint User B requests 
to conference in the endpoint User C. In a step 620, the 
endpoint User B sends the appropriate call setup infor- 
mation to its gatekeeper, GK1 , which then sends this 
information to the local MCUC 1 05a. In a step 622, the 
MCUC 105a accesses its database for information 
related to MCUs associated with the existing and 
requested parties to the conference. In particular, the 
MCUC 105a recognizes that the conference is to take 
place among two local parties, User A and User B, and 
one remote party, User C. 

[0032] In a step 623, the MCUC 105a identifies a 
local MCU, such as the MCU 104a, as being optimal, 
based on either network costs or coding resources cri- 
teria. In a step 624, the MCUC 1 05a activates the local, 
optimal MCU 104a, identifying the local parties to the 
conference and instructing the MCU 1 04a that a remote 
party, User C, exists. The MCU 104a then issues call 
setup commands and the like via the gateways 106a, 
106b, to the endpoint User C of the remote network, in 
a step 626. Again, these commands may be routed 
through the gatekeeper GK2, in a manner similar to that 
described above. 

[0033] In a step 628, the multipoint conference is 
established, with the MCU 104a handling mixing for the 
endpoints User A, User B and User C, and the MCUC 
105a updates its coding resource database. Then, in a 
step 630, one of the parties to the multipoint confer- 
ence, for example, User C, seeks to conference in 
another party, such as User D. The User C's request is 
received by the MCUC 105a. Accessing its database for 
optimal mixing in a step 632, the MCUC 1 05a notes that 
the endpoint User D is a member of the remote network 
100b. In a step 634, the MCUC 105a determines that 
mixing will be optimized if mixing between the endpoints 
User C and User D, on the one hand, and between end- 
points User A and User B, on the other, are handled 
locally, but that communications across the networks 
are optimized if mixing occurs across the MCUs 105a, 



105b. 

[0034] In a step 636, the MCUC 1 05a issues a com- 
mand to the MCU 104b of the network 100b to handle 
mixing for the endpoints User C and User D, and across 

5 the networks 100a and 100b, with the MCU 104a. The 
MCU 1 04a is similarly instructed to perform mixing for 
the local Users A and B and with the MCU 1 04b. 
[0035] The User C's media channel is thus rerouted 
to the MCU 104b, in a step 638. For example, the User 

w C may be disconnected by the MCU 104a and re-con- 
nected to the MCU 104b. Concurrently, the MCU 104b 
establishes a connection with the endpoint User D and 
the MCU 104a, in a step 640. 

[0036] In summary, according to embodiments of 
is the invention there is provided a multipoint control unit 
coordinator (MCUC) 1 05. The MCUC 105 tracks all con- 
ferences in a telecommunications system and deter- 
mines how they can be best configured and modified 
over time. The MCUC 1 05 instructs multipoint control 
20 units (MCUs) 1 04 to break down and reconfigure calls, 
if necessary. A MCUC 1 05 according to an embodiment 
of the invention maintains a database of all the MCUs 

104 in the system, a measure of processing coding 
resources, and a geographical location. When two par- 

25 ties seek to add a third in a conference call, the MCUC 

105 determines coding resources, geographical loca- 
tions, and determines the most appropriate mixing loca- 
tion based on preferences, such as network cost or 
endpoint coding resources or quality. The MCUC 105 

30 then instructs the MCUs 1 04 to handle the conference 
accordingly. 

Claims 

35 1. A telecommunications network, including: 



one or more multipoint control units (104) con- 
figured to perform call signaling between said 
MCU and a plurality of client endpoints, the net- 
work characterized by: 

a multipoint control unit coordinator (1 05), said 
multipoint control unit coordinator (105) config- 
ured to identify an optimal one of said one or 
more multipoint controllers (104) and direct 
said optimal one (104) to perform multipoint 
control functions. 



40 



45 



so 



55 



2. A telecommunications network according to Claim 
1, wherein said optimal one (104) is configured to 
be either one in which network costs are minimized 
for the conference, one which has maximum coding 
resources available for the conference, one in 
which network costs match predetermined criteria, 
or one in which coding quality required for the con- 
ference is maximized. 

3. A method for operating a telecommunications net- 
work, including the steps of: 
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receiving a multipoint conference set up 
request at a multipoint control unit coordinator 
(105); 

identifying one or more multipoint control units 
whose (104) use will be optimal according to s 
one or more criteria during said multipoint con- 
ference; and 

relaying said multipoint conference set up 
request to said one or more multipoint control 
units (105) after said optimal determination is 10 
made. 

4. A method according to Claim 3, wherein said deter- 
mining is made while a first multipoint conference is 
ongoing and said multipoint conference set up com- w 
mand seeks to add an additional party to said first 
multipoint conference. 

5. A method according to Claim 4, further comprising 
said multipoint control unit coordinator (1 05) trans- 20 
ferring control of said first multipoint conference 
from a first of said one or more multipoint control 
units (104) to a second of said one or more 
multipoint control units (104) when said additional 
party is added if said second is more optimal than 25 
said first. 

6. A method according to any of the preceding method 
claims, wherein said identifying is configured to 
identify one or more of said multipoint control units 30 
(104) whose use will minimize coding resources, 

will maximize coding quality, or will minimize net- 
work costs for said multipoint conference. 

7. A telecommunications device or system, including: 35 

means (290) for identifying one or more 
multipoint control units whose use will be opti- 
mal according to one or more criteria during a 
multipoint conference; and means (105) for 40 
relaying said multipoint conference set up 
request to said one or more multipoint control 
units after said optimal determination is made. 

8. A device or system according to Claim 7, wherein 45 
said identifying means (290) is operable to deter- 
mine said optimal one or more multipoint control 
units (104) while a first multipoint conference is 
ongoing and said multipoint conference set up com- 
mand seeks to add an additional party to said first 50 
multipoint conference. 

9. A device or system according to Claim 8, further 
comprising means (105) for transferring control of 
said first multipoint conference from a first of said 55 
one or more multipoint control units (104) to a sec- 
ond of said one or more multipoint control units 
(104) when said additional party is added and said 



second is more optimal than said first. 

10. A device or system according to any of the preced- 
ing system claims, wherein said identifying means 
is configured to identify one or more of said 
multipoint control units (104) whose use will mini- 
mize coding resources, will maximize coding qual- 
ity, or will minimize network costs for said multipoint 
conference. 
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